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PROTECTION OF DIGITAL CONTENT USING 
BLOCK CIPHER CRYTOGRAPHY 

RELATED APPLICATIONS 

[0001] This application claims the benefit of U.S. Provisional Application No. 
60/462,987, filed April 14, 2003. 
TECHNICAL FIELD 

[0002] This invention relates generally to the protection of digital content using 
cryptology, and more particularly to the protection of digital content using cipher block 
chaining. 

COPYRIGHT NOTICE/PERMISSION 

[0003] A portion of the disclosure of this patent document contains material which 
is subject to copyright protection. The copyright owner has no objection to the 
facsimile reproduction by anyone of the patent document or the patent disclosure as it 
appears in the Patent and Trademark Office patent file or records, but otherwise 
reserves all copyright rights whatsoever. The following notice applies to the software 
and data as described below and in the drawings hereto: Copyright © 2003, Sony 
Electronics, Inc., All Rights Reserved. 
BACKGROUND 

[0004] Digital Rights Management is a term used to describe the concept of 
protecting copyrighted material via encryption and governing its access via rules, 
typically distributed independently of the content. The protected content is usually 
inaccessible without a legitimately acquired license (embodying the rules governing the 
access) and software that securely interprets and releases the content if the appropriate 
license is available. This technology is promoted widely to music labels and other 
music/content distribution companies to use as a core technology for protecting their 
content. 

[0005] Certain content encryption problems arise especially in the context of 
streamable media (e.g. media such as music or video that may be streamed across a 
network and rendered (e.g., played) while being streamed rather than after the entire 
content is received or when read from a local file). In these cases, encryption may need 
to be done in real time, and lossy transport protocols may cause situations where not all 
the content sent is ever received at the client. For example, lost blocks of encrypted 
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data may cause the entire file to be unreadable. Furthermore, certain encryption 
techniques may increase the size of the digital content file. 
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SUMMARY OF THE INVENTION 

[0006] Protection of digital content using a specific application of block cipher 
cryptography is described. The digital content is encrypted using an encryption key 
and a calculated initialization vector. The digital content includes a plurality of strides 
of data and each stride includes a string of data to be encrypted and a block of data to 
be encrypted. The calculated initialization vector to be used to encrypt the block of 
data is derived from the string of data in the stride to be encrypted. Furthermore, the 
initialization vector is calculated by performing an exclusive disjunction function on a 
seed value and the string of data for each stride. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0007] Figure 1 is a diagram illustrating a system-level overview of an embodiment 
of the invention. 

[0008] Figure 2 illustrates one embodiment of a process flow for exchanging digital 
content within the network environment of Figure 1. 

[0009] Figure 3 A illustrates one embodiment of a digital content having multiple 
access units. 

[0010] Figure 3B illustrates one embodiment of the access unit of digital content 
having multiple strides. 

[001 1] Figure 3C illustrates one embodiment of a calculated IV value being derived 
from the access unit. 

[0012] Figure 3D illustrates one embodiment of a process flow for deriving the 
calculated IV value in conjunction with Figure 3C. 

[0013] Figure 3E illustrates one embodiment of a conceptual view for encrypting 
the access unit. 

[0014] Figure 3F illustrates one embodiment of a process flow for encrypting the 
access unit in Figure 3E. 

[0015] Figure 4 illustrates one embodiment of a process flow of the digital rights 
management software to encrypt the copyrighted raw digital content. 
[0016] Figure 5 illustrates one embodiment of a process flow for encrypting a 
partial stride. 

[0017] Figure 6 illustrates one embodiment of a process flow of the client 
decryption software to decrypt the encrypted digital content on a client device. 
[0018] Figure 7 illustrates one embodiment of a process flow for decrypting a 
partial stride. 

[0019] Figure 8 illustrates one embodiment of a computer system suitable for 
implementation. 
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DETAILED DESCRIPTION 

[0020] In the following detailed description of embodiments of the invention, 
reference is made to the accompanying drawings in which like references indicate 
similar elements, and in which is shown by way of illustration specific embodiments in 
which the invention may be practiced. These embodiments are described in sufficient 
detail to enable those skilled in the art to practice the invention, and it is to be 
understood that other embodiments may be utilized and that logical, mechanical, 
electrical, functional and other changes may be made without departing from the scope 
of the present invention. The following detailed description is, therefore, not to be 
taken in a limiting sense, and the scope of the present invention is defined only by the 
appended claims. 

[0021] Figure 1 illustrates one embodiment of a network environment 100. The 
network environment 100 includes a digital content provider server 10, client device 
20, client device 25, and client device 30. The digital content provider server 10 is part 
of, or coupled to a network 40, such as the Internet, to exchange data with each of the 
client devices (20, 25, 30), as either a client or a server computer. It is readily apparent 
that the present invention is not limited to use with the Internet; alternatively directly 
coupled and private networks are also contemplated. 

[0022] The digital content provider server 10 may store public domain or 
copyrighted digital content, such as digital music, electronic books, software source 
code, movies, etc. The digital content provider server 10 also includes a digital rights 
management component 5. The digital rights management component 5 includes 
encryption algorithms to encrypt the raw digital content for use by one or more 
authorized users of the digital content using the client devices (20, 25, 30). 
[0023] Each client device (20, 25, 30) includes a decryption component 7 and a 
digital content player component 8. The decryption component 7 provides for the 
decryption of encrypted digital content (e.g., digital content encrypted by the digital 
rights management component 5). The digital content player component 8 provides for 
the rendering of the digital content. Each client device (20, 25, 30) may be, for 
example, a personal computer, a portable digital music player, a portable digital video 
player, among other well-known examples of devices used to render digital content. 
[0024] Figure 2 illustrates one embodiment of a process flow (200) for exchanging 
digital content within the network environment of Figure 1. 
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[0025] At block 210, the digital rights management component 5 receives raw 
digital content. For example, the raw digital content may be a copyrighted digital 
music file or movie file. 

[0026] At block 220, the digital rights management component 5 encrypts the raw 
digital content using block cipher cryptology and a calculated initialization vector value 
derived from the digital content, as described below and in conjunction with Figures 
3A, 3B, 3C, 3D, 3E, and 4. In this way, the size of the digital content need not be 
increased, for example, by adding multiple initialization vectors when encrypted. 
[0027] At block 230, the digital rights management component 5 transmits the 
encrypted digital content to a client device (e.g., the client device 20) over the network 
40. The digital rights management component 5 also transmits the decryption key to 
decrypt the encrypted digital content. The decryption key may be the same as the 
encryption key value. The digital rights management component 5 may transmit the 
decryption key as part of the encrypted digital content or separately from the encrypted 
digital content. The digital rights management component 5 may also transmit a seed 
value as part of the encrypted digital content (e.g., a parameter value) or separately 
from the encrypted digital content. 

[0028] At block 235, the client device 20 receives the encrypted digital content. 
[0029] At block 240, the decryption component 7 of client device 20 decrypts the 
digital content using at least the decryption key and a calculated initialization vector 
derived from the digital content, as will be further described below and in conjunction 
with Figure 6. 

[0030] At block 250, the digital content player component 8 on the client device 20 
facilitates the rendering of the decrypted digital content. For example, the digital 
content player component 8 may be a music player software application to render the 
decrypted music file. 

[0031] The following will define various parameters of an encryption and 
decryption algorithm process, and illustrate various examples of applying the algorithm 
process to streaming media using parameter values. Specifically, the following 
describes encryption and decryption of logical units (e.g., access units) of the digital 
content based on block cipher cryptology using a calculated IV value, as will be 
described. A block cipher is a method of encrypting plaintext (to produce ciphertext) in 
which a cryptographic key (e.g., an encryption key) and an algorithm are 
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simultaneously applied to all bits in a block of data (for example, 64 contiguous bits) at 
once as a group rather than to one bit at a time. It should be understood that plaintext 
and ciphertext are terms of art that represent unencrypted and encrypted data 
respectively. 

[0032] As will be shown, the digital content is subdivided into logical units (e.g., 
access units) and each of these logical units is encrypted independently using block 
cipher cryptography. In this way, if a specific portion of the encrypted digital content 
file is lost (e.g., while transmitting the digital content file), the decryption of the 
remaining portion of the digital content file can be restarted at the next logical section. 
[0033] Figure 3 A illustrates one embodiment of a digital content 300 having 
multiple access units. Specifically, the digital content 300 includes access unit 310, 
access unit 315, access unit 320, and access unit 325. The access units are chosen so 
that their content is a logical subdivision of the digital content, definable and 
addressable without knowledge of the data content itself. The access units are also 
small enough so that losing part of the digital content during transmission, for example, 
will not drastically affect rendering. The access unit may be an intrinsic property of the 
digital content (e.g., mpeg4 defined access unit) or defined as a parameter to the 
decryption component 7. Each access unit includes multiple strides. 
[0034] Figure 3B illustrates one embodiment of the access unit 310 of digital 
content 300 having multiple strides. A stride is a predefined length of data within an 
access unit. Specifically, access unit 310 includes stride 340, stride 345, stride 350, and 
stride 355. Within each stride (340, 345, 350, 355) there exists a block of data to be 
encrypted. The following describes a portion of the strides being encrypted with one or 
more block cipher modes of operation. For example, one mode is the electronic 
codebook (ECB) mode, in which a string of data to be encrypted is split into blocks 
(e.g., 16 byte blocks) and each block is encrypted separately. 

[0035] Another example of a mode of block cipher is cipher-block chaining (CBC), 
in which each block of plaintext is split into blocks (e.g., 16 byte blocks) and is XORed 
with a previous ciphertext block before being encrypted. In order to prevent repeated 
encryption of same plaintext to result in identical ciphertext, CBC typically uses a 
different initialization vector (IV) to start each encryption sequence (e.g., access unit). 
[0036] Typically, the inclusion of the initialization vector alongside each encrypted 
block sequence (or logical unit) would cause the file size to increase because one or 
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more initialization vectors are embedded into the encrypted digital content to be 
delivered to the decryption component 7. This may be problematic if the digital 
content includes an index to specific locations in the digital file (e.g., a location of a 
scene in a digital movie file, a location of a specific song track on a music CD (compact 
disk), etc.) because the inclusion of the initialization vector will cause a shift of the 
physical header locations, thereby possibly making the files unreadable (unless they are 
recalculated prior to transmitting the file. 

[0037] In one embodiment, the digital rights management component 5 encrypts 
the raw digital content using an initialization vector algorithmically calculated from a 
chosen string of data chosen from each stride of data to be encrypted for each access 
unit, under the assumption that the chosen string of data will be different enough from 
access unit to access unit that the result is a different initialization vector for each 
access unit to be encrypted. 

[0038] Figure 3C illustrates one embodiment of a calculated IV value being derived 
from the access unit 310. The first 16 bytes of each stride are illustrated as string of 
data 342, string of data 347, string of data 352, and string of data 357. Figure 3D 
illustrates one embodiment of a process flow 360 for deriving the calculated IV value in 
conjunction with Figure 3C. 

[0039] At block 3 65, the digital rights management component 5 obtains a seed 
value 328. The seed value defines the initial value of the initialization vector. 
[0040] At block 370, the digital rights management component 5 performs an 
exclusive disjunction function (e.g., XOR function) on the seed value 328 and the string 
of data 342 of the first stride 340 of the access unit 310 resulting in an initial IV value. 
[0041] At block 375, the digital rights management component 5 determines 
whether there is another stride in the access unit 310. If there is another stride in the 
access unit 310, control passes to block 380. If there is not another stride in the access 
unit 310, control passes to block 385. Continuing the example, the digital rights 
management component 5 would determine the next stride to be stride 345. 
[0042] At block 380, the digital rights management component 5 performs an XOR 
on the current initial IV value with the string of data 347 of the stride 345, resulting in 
an updated initial IV value. Control passes back to block 375 where the process repeats 
for string of data 352 and 357. 
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[0043] At block 385, the digital rights management component 5 sets a calculated 
IV value 305 to the current initial IV value. In one embodiment, the calculated IV 
value 305 is supplied to the underlying AES CBC cipher of the digital rights 
management component 5 to encrypt specific blocks of data within the access unit 310. 
[0044] It should be understood that the invention is not limited to deriving the 
calculated IV value based on the first 16 bytes of each stride. Rather, in alternative 
embodiments, the calculated IV value may be derived from a set of implementation 
specific sections (e.g., 16 byte string of data) of an access unit, so that the decryption 
software knows where to find the specific sections. Preferably, the specific sections 
should have a high probability of resulting in sufficient randomness to generate a 
reasonably unique calculated IV value for each access unit. 

[0045] It should also be noted that although the embodiments described herein use 
the seed value 328 when deriving the calculated IV value, the seed value 328 is not 
necessary, and the calculated IV value may be derived without using the seed value 
328. For example, the calculated IV value may be calculated from XORing the first 16 
bytes of each stride of an access unit without including the seed value 328. 
[0046] Figure 3E illustrates one embodiment of a conceptual view for encrypting 
the access unit 310 using the calculated IV value 305 described above and in 
conjunction with Figures 3C and 3D. Figure 3F illustrates one embodiment of a 
process flow 390 for encrypting the access unit 310 in Figure 3C. The following shows 
the encryption process using an encryption key value (Kc) and a calculated IV value, as 
input parameters. 

[0047] At block 392, the digital rights management component 5 obtains the 
calculated IV value 305, as described above. 

[0048] At block 394, the digital rights management component 5 encrypts 85 the 
blocks of data 344, 349, 354, and 359 using the calculated IV value 305 and an 
encryption key 82 (Kc). In one embodiment, the encryption key value is a 16-byte 
(128-bit) value, randomly regenerated, that serves as the encryption key in the AES 
algorithm. The blocks of data 344, 349, 354, and 359 are encrypted using a cipher 
block chaining block cipher mode. Block of data 344c, 349c, 354c, and 359c represent 
the resulting encrypted blocks of data. 

[0049] At block 396, the strings of data 342, 347, 352, and 357 are encrypted. The 
strings of data 342, 347, 352, and 357 are encrypted using an electronic code book 
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block cipher mode. Strings of data 342c, 347c, 352c, and 357c represent the resulting 
encrypted strings of data. 

[0050] Processes 360 and 390 may be repeated for each access unit of the digital 
content to be encrypted. It should be appreciated that in this way the digital content 
300 will not increase in size nor cause header location shifts. That is, the encrypted 
digital content will remain the same size as the unencrypted digital content. This is 
because the encrypted digital content does not include an initialization vector from 
another source, such as from the data of a previously encrypted stride or a timestamp. 
Furthermore, the data required to reconstruct the IV is accessible from the cipher text 
block at decryption time, as will be described. 

[0051] In one embodiment, the digital rights management component 5 includes an 
encryption algorithm based on the Advanced Encryption Standard, more commonly 
referred to as AES, which is a block cipher with a block size of 128 bits (e.g., 16 bytes) 
and key sizes of 128, 192, and 256 bits. However, the invention is not limited to using 
AES. Alternative algorithms well known to those of ordinary skill in the art may be 
used and are not described herein so as not to obscure the description. 
[0052] In one embodiment, the digital rights management component 5 and the 
decryption component 7 use a number of parameter values in addition to the encryption 
key value, and the calculated IV value, to facilitate the encryption and decryption of the 
digital content. The parameter values may include, but are not limited to, an access unit 
size value, an encryption stride size value, a complete encryption value, an encryption 
chunk offset value, an encryption chunk size value, and an IV stride count value. 
[0053] The access unit size value defines the size of the access unit being processed 
by the digital rights management component 5. In one embodiment, each access unit 
may be of different sizes and its boundaries are identifiable, which is well known to 
those of ordinary skill in the art. 

[0054] The encryption stride size value defines the length of a stride. In one 
embodiment, a typical value for the encryption stride size value is 512 bytes. An 
access unit need not be an even multiple of the encryption stride size value. The last 
stride in an access unit may, therefore, be shorter than the encryption stride size value. 
[0055] The complete encryption value is a flag used to identify a percentage of 
encryption to be applied or the percentage of encryption that has been applied to a 
digital content file. The following description describes processing performed at 100% 
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encryption and 25% encryption, for example. However, the invention is not limited to 
these encryption percentages. Alternatively, the digital rights management software 
may encrypt the digital content at other percentages. 

[0056] The encryption chunk offset value defines an offset from the beginning of a 
stride to a block of data to be encrypted, as will be further described. 
[0057] The IV stride count value defines the number of strides that contribute to a 
calculated IV value. In one embodiment, the IV value used in the AES CBC 
processing (e.g., the calculated IV value) is calculated from the contents of the access 
unit to be encrypted. If the size of the access unit is less than the (IV stride count value 
* the encryption stride size value), the IV stride count value is adjusted by the digital 
rights management component 5 such that only as many strides as there are full strides 
in the access unit contribute to the calculated IV value. If the last stride is partial (e.g., 
if the last stride is less than the encryption stride size value), the IV stride count value is 
such that this partial stride should contribute to the calculated IV value. Furthermore, 
the partial stride does contribute if it is at least 16 bytes in length. Otherwise, that 
stride is ignored as far as the calculated IV value contribution is concerned. In our 
example we also limit the number of blocks contributing to the calculated IV value to 
four. 

[0058] The encryption chunk size value defines a size of the block of data to be 
encrypted. In one embodiment, the encryption chunk size should be less than or equal 
to (the encryption stride size value minus the encryption chunk offset value). Since the 
AES implementation requires block sizes greater than or equal to 16 bytes (equal to key 
size. . .), the encryption chunk size value is greater than or equal to 16 bytes. Also, the 
encryption chunk size value should be a multiple of the AES block size (16 bytes). For 
example, in one embodiment, there are two values of the encryption chunk size: 496 
bytes and 128 bytes. For 100% encryption, the value of the complete encryption 
parameter is set to "true", and the entire stride (512 bytes) is encrypted where 496 bytes 
are encrypted using AES CBC and the 16 bytes of content contributing to the calculated 
IV value are encrypted with AES ECB. 

[0059] Figure 4 illustrates one embodiment of a process flow 400 of the digital 
rights management component 5 to encrypt the copyrighted raw digital content based 
on the parameter values. 
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[0060] At block 405, the digital rights management component 5 determines the 
access unit size value of an access unit to be encrypted. If the access unit size value is 
less than 32 bytes, control passes to block 410. If the access unit size value is greater 
than or equal to 32 bytes, control passes to block 440. 

[0061] At block 410, the digital rights management component 5 determines the 
complete encryption value. If the complete encryption value is set to "false," control 
passes to block 41 1. If the complete encryption value is set to "true," control passes to 
block 413. 

[0062] At block 411, the access unit is not encrypted but remains plaintext and 
control passes to block 465. The access unit may not be encrypted here because the 
access unit size is less than 32 bytes and other portions of the digital content may have 
been encrypted enough to make encrypting this access unit unnecessary. 
[0063] At block 413, the digital rights management component 5 determines if the 
access unit size value is greater than zero bytes and less than 16 bytes, control passes to 
block 415. At block 414, if the access unit size value is 16 bytes, control passes to 
block 420. If the access unit size value is greater than 16 bytes and less than 32 bytes, 
control passes to block 425. 

[0064] At block 415, the digital rights management component 5 performs an XOR 
function on the data comprising the access unit (e.g., the n access unit bytes) with the n 
leftmost bytes of E(Kc, seed value), and control passes to block 465. 
[0065] At block 420, the digital rights management component 5 encrypts the 1 6 
access unit bytes with AES using ECB mode and control passes to block 465. 
[0066] At block 425, the digital rights management component 5 calculates the 
calculated IV value by performing an XOR function on the seed value and the first 16 
bytes of the access unit. 

[0067] At block 430, the digital rights management component 5 encrypts the first 
16 bytes of the access unit with AES using ECB mode. 

[0068] At block 435, the digital rights management component 5 performs an XOR 
function on the remaining n-16 bytes, with the n leftmost bytes of E(Kc, calculated IV 
value) and control passes to block 465. 

[0069] At block 440, the digital rights management component 5 checks and 
initializes the parameters values previously described above. The digital rights 
management component 5 sets the IV stride count value to the number of strides in the 
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access unit. The IV stride count value is calculated as being the access unit size value 
divided by the encryption stride size value. 

[0070] Any fractional stride left over counts as a partial stride. However, it should 
be understood that if the last (possibly partial) stride is less than 16 bytes in length, and 
this stride would contribute to the calculated IV value due to the IV stride count's value 
being equal to the number of strides in the access unit, then the IV stride count value is 
decremented by one, so that less-than- 16-byte fragments are not used. 
[0071] The digital rights management component 5 sets the encryption chunk offset 
value. In one embodiment, the encryption chunk offset value is set to 16 bytes. 
[0072] At block 445, the digital rights management component 5 determines a 
calculated IV value. In one embodiment, the calculated IV value is derived from the 
first 16 bytes of each of the first IV stride count values of the access unit as described 
above and in conjunction with Figures 3C and 3D. 

[0073] At block 450, the digital rights management component 5 determines 
whether to encrypt the entire raw digital content. If the value of the complete 
encryption value is set to "true," control passes to block 455. If the complete 
encryption value is set to "false," control passes to block 460. 
[0074] At block 455, the digital rights management component 5 encrypts the 
random 16 byte string of data of each stride used to calculate the calculated IV value. 
For example, the digital rights management component 5 encrypts the first 1 6 byte 
string of data of each stride using AES with the Electronic Code Book (ECB) mode. In 
one embodiment, no calculated IV value is involved in this calculation. 
[0075] At block 460, the digital rights management component 5 encrypts the 
remaining block of data with AES using CBC mode. For example, the digital rights 
management component 5 encrypts the block of data starting at the encryption chunk 
offset from the start of the stride and encryption chunk size in length. Hence, the 
calculated IV value is used as the initial IV value for the AES cipher (as described in 
3E and 3F for each access unit). In one embodiment, each applicable block of data in 
each stride are part of the same AES cipher block chain started for each access unit. In 
an alternative embodiment, AES is restarted with each stride. 
[0076] At block 465, the digital rights management component 5 transmits the 
encrypted digital content to the client device. 
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[0077] It should be understood that the calculated IV value is not limited to being 
derived from the first 16 bytes of each stride of the access unit to be encrypted. Rather, 
in alternative embodiments, the calculated IV value may be derived from any random 
16 byte (but well specified in location) string of data from each stride of the access unit 
to be encrypted. 

[0078] It should be appreciated that special processing occurs for the remaining 
blocks that are not an exact multiple of the AES block size (16 bytes). For all strides 
except the last one, the blocks will be an integral multiple of the AES block size (e.g., 
16 bytes). However, a short access unit may result in a partial stride (e.g., having a 
block size less than 16 bytes). 

[0079] Figure 5 illustrates one embodiment of a process flow 500 for encrypting a 
partial stride. 

[0080] At block 510, the digital rights management component 5 encrypts the 
cipher text of the last full block with AES ECB (e.g. not, for example, the block used to 
derive the calculated IV if that happens to be the previous full block) using AES ECB 
(all encryption is done using the same, original, input encryption key). 
[0081] At block 520, the digital rights management component 5 calculates a 
partial bit value as the number of bits in the partial block. 

[0082] At block 530, the digital rights management component 5 performs an XOR 
function on the left-most bits of the last full block equaling the partial bits value with 
the partial block of the stride to generate the corresponding cipher text. 
[0083] It should be understood that process 400 and process 500 will be repeated 
for each access unit in the digital content. Alternatively, the digital rights management 
component 5 may encrypt specific or partial strides of the digital content for quick 
encryption of digital content, for example. 

[0084] Figure 6 illustrates one embodiment of a process flow 600 of the decryption 
component 7 to decrypt the encrypted digital content on a client device. 
[0085] At block 605, the client device receives encrypted digital content (and 
determines the decryption parameters - possibly from data in the content file, e.g. 
partial or full encryption, seed IV value, stride size, etc. . .). 

[0086] At block 610, the decryption component 7 determines the access unit size 
value of an access unit to be decrypted. If the access unit size value is less than 32 
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bytes, control passes to block 615. If the access unit size value is greater than 32 bytes, 
control passes to block 655. 

[0087] At block 615, the decryption component 7 determines the complete 
encryption value. If the complete encryption value is set to "false," control passes to 
block 620. If the complete encryption value is set to "true," control passes to block 
625. 

[0088] At block 620, the decryption component 7 determines the access unit is not 
encrypted and process 600 ends. 

[0089] At block 625, the decryption component 7 determines if the access unit size 
value is greater than zero bytes and less than 16 bytes, control passes to block 630. At 
block 626, if the access unit size value is 16 bytes, control passes to block 635. If the 
access unit size value is greater than 16 bytes and less than 32 bytes, control passes to 
block 640. 

[0090] At block 630, the decryption component 7 performs an XOR function on the 
data comprising the access unit (e.g., the n access unit bytes) with the n leftmost bytes 
of D(Kc, seed value), and the process 600 ends. 

[0091] At block 635, the decryption component 7 decrypts the 16 access unit bytes 
with AES using ECB mode and the process 600 ends. 

[0092] At block 640, the decryption component 7 decrypts the first 16 access unit 
bytes with AES using ECB mode. 

[0093] At block 645, the decryption component 7 calculates the calculated IV value 
by performing an XOR function on the seed value and the remaining 16 bytes of the 
access unit. 

[0094] At block 650, the digital rights management component 5 performs an XOR 
function on the remaining n-16 bytes with the n leftmost bytes of D(Kc, IV calculated 
value). 

[0095] At block 655, the digital rights management component 5 checks and 
initializes the parameter values. The digital rights management component 5 sets the 
IV stride count value to the number of strides in the access unit. The IV stride count 
value is calculated as being the value of access unit size value divided by the 
encryption stride size value. 

[0096] At block 660, the decryption component 7 determines the complete 
encryption value of the received digital content. If the complete encryption value is 
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"True," control passes to block 665. If the complete encryption value is "False," 
control passes to block 675. 

[00971 At block 665, the decryption component 7 decrypts the block of data 
contributing to the calculated IV value. For example, the first 16 byte string of data of 
the stride (cipher text) for each of IV stride count values are decrypted. The decryption 
may intrinsically know the location of the blocks of data contributing to the calculated 
IV value or locations may be passed as parameters in an alternative embodiment. In 
one embodiment, no IV is involved in the decryption. 

[0098] At block 675, the decryption component 7 determines the calculated IV 
value. In one embodiment, the calculated IV value is derived by performing an XOR 
function on a 16 byte string of data from each stride with a seed value, as described 
above. The seed value may have been transmitted separately from the digital content or 
appended to the digital content. 

[0099] At block 685, the decryption component 7 decrypts the remaining encrypted 
block of data using AES CBC and the calculated IV value. 

[00100] At block 690, the decryption component 7 decrypts the partial stride, if 
necessary. In one embodiment the partial stride is decrypted as described in Figure 7. 
[00101] It should be understood the process 600 may be repeated for each access 
unit in the digital content as needed. 

[00102] Figure 7 illustrates one embodiment of a process flow 700 for decrypting a 
partial block (as in less than key length). 

[00103] . At block 720, the digital rights management component 5 calculates a 
partial bits value as the number of bits in the partial block. 

[00104] At block 730, the digital rights management component 5 performs an XOR 
function of the bits of the partial block with the n left-most bits of the last full block (n 
equaling the number of bits in the partial block), to generate the corresponding cipher 
text. 

[00105] Figure 8 illustrates one embodiment of a computer system suitable for 
performing the features of an embodiment of the invention. The computer system 840 
includes a processor 850, a memory 855, and an input/output capability 860, all 
coupled to a system bus 865. Such a configuration encompasses personal computer 
systems, network computers, television based systems, such as Web TVs or set-top 
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boxes, handheld devices, such as portable music players, digital video players, mobile 
phones and personal digital assistants, and similar devices. 
[00106] The processor 850 represents a central processing unit of any type of 
architecture, such as a CISC, RISC, VLIW, DSP, or hybrid architecture. In addition, 
the processor 850 could be implemented on one or more chips. The memory 855 is 
configured to store instructions which, when executed by the processor 850, performs 
the methods described herein. The memory 855 may also store the user information 
and the contact information. 

[00107] Input/output 860 may include components to facilitate user interaction with 
the computer system 840 such as a keyboard, a mouse, a display monitor, a 
microphone, a speaker, a display, a network card (e.g., Ethernet, Inferred, cable 
modem, Fax/Modem, etc.), etc. Input/output 860 also encompasses various types of 
machine-readable media, including any type of storage device that is accessible by the 
processor 850. For example, a machine-readable medium may include read only 
memory ("ROM"); random access memory ("RAM"); magnetic disk storage media; 
optical storage media; flash memory devices; electrical, optical, acoustical, or other 
forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.). 
Thus, a machine-readable medium includes any mechanism that provides (i.e., stores 
and/or transmits) information in a form readable by a machine (e.g., a computer). One 
of skill in the art will immediately recognize that the term "machine-readable 
medium/media" further encompasses a carrier wave that encodes a data signal. 
[00108] It will also be appreciated that the operating system software executing the 
digital rights management component 5, the decryption component 7, and the digital 
content player 8 stored in memory 855 may control the computer system 840. The 
operating system may be, for example, PC-based, Mac-based, Unix-based, Palm OS, 
etc. Input/output and related media 860 store the machine-executable instructions for 
the operating system and methods of the present invention. 

[00109] In addition, the bus 865 may represent one or more busses (e.g., PCI, ISA, 
X-Bus, EISA, VESA, etc.) and bridges (also termed as bus controllers). While this 
embodiment is described in relation to a single processor computer system, the 
invention could be implemented in a multi-processor computer system. 
[00110] The description of Figure 8 is intended to provide an overview of computer 
hardware and other operating components suitable for implementing the invention, but 
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is not intended to limit the applicable environments. It will be appreciated that the 
computer system 840 is one example of many possible computer systems that have 
different architectures. A typical computer system will usually include at least a 
processor, a memory, and a bus coupling the memory to the processor. One of skill in 
the art will immediately appreciate that the invention can be practiced with other 
computer system configurations, including multiprocessor systems, minicomputers, 
mainframe computers, and the like. The invention can also be practiced in distributed 
computing environments where tasks are performed by remote processing devices that 
are linked through a communications network. 

[001 11] It will be appreciated that more or fewer processes may be incorporated into 
the methods illustrated in Figures 2, 3D, 3F, 4, 5, 6, and 7, without departing from the 
scope of the invention and that no particular order is implied by the arrangement of 
blocks shown and described herein. It will be further appreciated that the method 
described in conjunction with Figures 2, 3D, 3F, 4, 5, 6, and 7, may be embodied in 
machine-executable instructions, (e.g., software). The instructions can be used to cause 
a general-purpose or special-purpose processor that is programmed with the 
instructions to perform the operations described. Alternatively, the operations might be 
performed by specific hardware components that contain hardwired logic for 
performing the operations, or by any combination of programmed computer 
components and custom hardware components. The methods may be provided as a 
computer program product that may include a machine-readable medium having stored 
thereon instructions, which may be used to program a computer (or other electronic 
devices) to perform the methods. For the purposes of this specification, the term 
"machine-readable medium" shall be taken to include any medium that is capable of 
storing or encoding a sequence of instructions for execution by the machine and that 
causes the machine to perform any one of the methodologies of the present invention. 
The term "machine-readable medium" shall accordingly be taken to include, but not be 
limited to, solid-state memories, optical and magnetic disks, and carrier wave signals. 
Furthermore, it is common in the art to speak of software, in one form or another (e.g., 
program, procedure, process, application, module, logic, etc.), as taking an action or 
causing a result. Such expressions are merely a shorthand way of saying that execution 
of the software by a computer causes the processor of the computer to perform an 
action or to produce a result. 
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[001 12] Protection of digital content using block cipher cryptography has been 
described. It should be appreciated that the encryption does not change the size of the 
encrypted data and therefore any additional headers necessary to decrypt do not need to 
be adjusted. Furthermore, it is possible to resume decrypting the streamed content 
even if some packets are lost during transmission. Encryption chains are and can be 
restarted at close enough intervals so as to not destroy the viewing experience when 
packet loss occurs. This is due to the capability to derive the calculated IV value at 
whichever point the decryption is restarted, and to the fact that the CBC is restarted at 
well defined intervals (e.g., access units) that are known without decrypting the content. 
Also, it should be appreciated that to improve the security of CBC, the calculated IV 
value is different each time it is used with the same key. Since one of the goals of the 
method is to not add data to the file, the calculated IV value is generated from 
reasonably random data collected from the sample to be encrypted itself. 
[00113] Furthermore, a mechanism for partial media encryption has been disclosed 
that parameterizes the amount of encryption so that for less capable devices, less than 
100% encryption can be used. 

[00114] It should be understood that the digital rights management component 5 
may perform additional checks and initializations than those disclosed above. For 
example, the digital rights management component 5 checks if the encryption chunk 
size value is less than or equal to (the encryption stride size value minus the encryption 
chunk offset value). Furthermore, the encryption chunk size value may be checked to 
ensure it is a multiple of the AES block size (16 bytes). 

[00115] While the invention has been described in terms of several embodiments, 
those skilled in the art will recognize that the invention is not limited to the 
embodiments described. The method and apparatus of the invention can be practiced 
with modification and alteration within the scope of the appended claims. The 
description is thus to be regarded as illustrative instead of limiting on the invention. 
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